System and method for transferring data with electronic messages

ABSTRACT

The invention relates to sharing patient care information through electronic messaging. Systems for managing electronic health records may comprise extensive patient information, e.g., names, addresses, insurance coverage and/or other financial arrangements, health conditions, allergies, procedures undergone, and/or tests performed. The invention involves transfer of such information between users. Embodiments of the invention may pass such information by adding to electronic messages pointers that uniquely refer to one or more patient records. Some embodiments may thereby send health information electronically while preserving metadata and/or other meaning associated with the data.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application no.11/112,696, filed 29 Dec. 2005 and titled “System and Method forTransferring Data with Electronic Messages,” now U.S. Pat. No.8,626,524, which is incorporated herein by reference in its entirety.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightswhatsoever.

BACKGROUND Electronic Messaging

The present invention relates to the use of electronic messages totransfer data. More particularly, it involves the transfer of data inelectronic messages with no loss of semantic data and/or other metadataor other meaning associated with the data, with application to thetransfer of medical data.

Electronic messaging comprises the use of computerized services to sendand receive electronic data, which may comprise, e.g., text, audio,video, and/or other electronic data.

Many forms of electronic messaging are well known, e.g., electronic mail(or email) and instant messaging. For example, depending on the system,email may comprise a system for sending asynchronous messages to one ormore users. Again depending on the system, an email message may comprisea title or subject, a body that primarily comprises text, and/or one ormore attachments, which may comprise computer files and/or otherelectronic data.

According to the prior art, an attachment to an electronic message isoften a computer file. Attaching the file comprises including arepresentation of the entire contents of the file and descriptive datain the representation of the electronic message. When the electronicmessage is received, the attachment may be extracted and possibly savedas a new file by the recipient.

In some instances, a sender may itself be a computer program or system.For example, a computer may be configured to periodically transfer a logas an electronic message. Such a message may be composed and transferredwithout human intervention.

The transport and representation of electronic messages as email acrossthe Internet 7 are well known and described in publicly-availableInternet standards, which are called Requests for Comment (“RFCs”).Relevant RFCs comprise RFC2822 (available athttp://www.ietf.org/rfc/rfc2822.txt), RFC2045 (available athttp://www.ietf.org/rfc/rfc2045.txt), RFC2046 (available athttp://www.ietf.org/rfc/rfc2046.txt), RFC2047 (available athttp://www.ietf.org/rfc/rfc2047.txt), RFC2048 (available athttp://www.ietf.org/rfc/rfc2048.txt), and RFC2049 (available athttp://www.ietf.org/rfc/rfc2049.txt), among others. Other ways torepresent and/or transport electronic messages are also well known. Asdescribed in these RFCs, the representation of an electronic messagecomprises representations of the message and the content of anyattachments.

Electronic Health Records

A number of things have driven the growth in all aspects of the healthcare industry of computerized systems providing Electronic HealthRecords (EHRs) and Electronic Medical Records (EMRs). (The term “EHRsystem” is used herein to refer to any computerized system that maystore, maintain, and/or provide EHRs. This term may have othersignificance in other contexts.) For example, governmental regulationcontinues to move towards impelling the adoption of EHR systems. Inaddition, EHR systems reduce the chances of loss of patient records andmistakes in data entry and make delivery of health care more efficient,thereby offering the prospects of improving patient care while loweringits cost. Further, EHR systems may help ease the burden of paperworkthat now afflicts the delivery of health care.

An EHR system may record and aggregate any type of data associated withhealth care, including, e.g., data about patients, including, e.g.,their names, addresses, insurance coverage and/or other financialarrangements, health conditions, allergies, procedures undergone, and/ortests performed. Other recorded data may relate to, among other things,health care providers, payers, pharmacies, and/or employers.

Electronic data of any sort is often associated with other data thatdescribes it, provides context for it, associates it with other data,and/or otherwise signifies the meaning, significance, and/or one or moreother attributes of the electronic data. This accompanying data is oftencalled “metadata.”

For example, in the medical field, an application may display theresults of a blood test for cholesterol levels. The display may includedata such as the levels of total cholesterol, HDLs, and LDLs, amongother data. Some or all of this data may be associated with furtherdata, such as the date of the test, the location where the blood samplewas drawn, the identity of the laboratory (“lab”) that analyzed thesample, the identity of the patient, and the identity of thepractitioner who ordered the test, and this further data can beconsidered metadata. The appropriate characterization of data sometimesdepends on the ways in which it is treated in computerized files,applications, and/or systems.

A health care provider may wish to transfer data, contained in an EHRsystem, about one or more patients, to other providers, for example, inconnection with a medical consultation.

BRIEF SUMMARY

According to embodiments of the invention, data may be attached to anelectronic message in the form of a reference that uniquely specifies aparticular set of data, rather than including the data itself in themessage. On receipt, the reference may be used to retrieve the attacheddata from a store for delivery to the recipient. For example, a computerfile may be specified by a reference that comprises the name of a serverand the path to the file on the server. When the recipient opens orviews the message, the recipient's computer system may then contact thenamed server and request delivery of the specified file.

An embodiment of the invention may alternatively use a reference tospecify a set of data that is not a file. For example, a reference mayspecify a record or set of related records in a database. In arelational database management system, such as is well known, a recordmay exist as a row in a table or as linked rows in one or more tables. Aprimary key uniquely specifies a row, and an embodiment of the inventionmay therefore use a primary key as the reference. Alternatively, anembodiment may generate a unique identification code for use as areference and then associate the code with the primary key of theattached data. An embodiment of the invention may also supportassociation of more than one primary key with a single identificationcode, causing the system to provide multiple records when presented withthe identification code.

Similar techniques are applicable to other sorts of databases, such asobject-oriented databases.

When used to identify a set of data, a reference may specify structureddata sets of varying complexity. For example, an application related toelectronic commerce may in some contexts treat a customer's order as asingle, atomic entity, even though the data associated with the order isstored in multiple records in a database. (Such a contextual entity issometimes referred to herein as a “data item.”) But that sameapplication may in other contexts treat the same order as a compositeentity, comprising, e.g., a customer, a payment, a shipper, and one ormore ordered items, each of which may itself be considered a data itemin this context. These other data items may themselves be regarded inother contexts as composites that comprise more primitive data items,and so on. (The term “hierarchical data item” is intended to refer todata items that may also be considered as composites of more primitivedata items.)

A reference may point to data that is associated with other data thatindicates meaning, context, or both. This other data (referred to hereinas “semantic data”), may, e.g., indicate that a particular value is aprice or quantity, has a particular data type, and a computerapplication may rely on such semantic data to be able to process thedata automatically. Semantic data may be explicit, such as an explicitspecification of a data type, which is linked to data. Semantic data mayalso be implicit: the meaning of a set of values may sometimes beinferred from the database table in which they are found. Depending onthe embodiment of the invention, a reference in an electronic messagemay refer to data in its original context of semantic data and supportaccess to such semantic data by the recipient of the message.

In an embodiment of the invention, data is transferred via an electronicmessage that encodes a unique reference to some or all of the data. Inan embodiment of the invention, sending data with an electronic messageinvolves attaching to the electronic message unique references to one ormore records that comprise the data. In a further embodiment of theinvention, when the recipient saves a persistent copy of the receiveddata, the database records that contain the data are duplicated, andfurther manipulation of the received data by the recipient involves thepersistent copy of the data.

In an embodiment of the invention, data associated with semantic datamay be transferred and/or duplicated by receiving an electronic messagethat comprises at least one reference that uniquely specifies a set ofdata, wherein the set of data comprises one or more original data itemsthat are associated with semantic data; presenting the electronicmessage to a recipient at a first computer system; in response to inputto the first computer system, presenting at the first computer systemsome or all of the data comprised by the set of data; and, in responseto further input to the first computer system, creating a persistentcopy of some or all of the data comprised by the set of data; whereincreating a persistent copy comprises creating a persistent copy of atleast one of the one or more original data items that are associatedwith semantic data, such that each copy of a data item is associatedwith the same semantic data that the corresponding original data item isassociated with.

In an embodiment of the invention, data associated with semantic datamay be transferred and/or duplicated by receiving an electronic messagethat comprises at least one reference that uniquely specifies ahierarchical data item that comprises a plurality of data items;presenting the electronic message to a recipient at a first computersystem; presenting to the recipient at the first computer system a userinterface that comprises a display of a plurality of the plurality ofdata items comprised by the hierarchical data item and user interfacecomponents supporting individual selection of each data item; inresponse to input to the first computer system, selecting one or more ofthe displayed data items; and in response to further input to the firstcomputer system, creating a persistent copy of each selected data item.In another embodiment of the invention, a reference may uniquely specifya collection of one or more hierarchical data items that each comprise aplurality of data items.

An embodiment of the invention may be implemented in association with acomputerized EHR system that comprises, among other patient carefeatures, electronic lab test ordering, online delivery and viewing oflab results, and electronic eligibility checking and prescribing. An EHRsystem in association with which an embodiment of the invention can beimplemented may provide patient care features that support some or allof a set of tasks comprising, among others:

ordering lab tests;

accessing and viewing lab results;

providing clinical insights at the time of ordering, delivering results,or both;

preparing and ordering drug prescriptions;

performing Pharmacy Benefit Manager (PBM) eligibility checks, includingpharmacy coverage, PBM formulary, and patient medication history;

performing drug-to-drug interaction checking per prescription, as wellas across a patient's active medications and medication history;

performing drug-to-allergy interaction checking per prescription;

communicating prescriptions to pharmacies and/or receiving requests frompharmacies for prescription refills.

managing clinical documents received from external systems;

communicating clinical data securely within and between physicianoffices;

viewing data by patient, user, and organization;

analyzing patient data using various tools, including flowsheets,graphs, and informatics queries;

accessing a user-configurable inbox for both clinical and non-clinicaldata;

maintaining associations of physicians-to-provider organizations,physicians-to-payer plans, and physicians-to-specialties;

communicating with one or more labs to gain assistance in interpretingresults;

communicating with one or more labs to order supplies; and

accessing information provided by one or more labs, such informationcomprising, for example, test dictionaries, lab manuals, and PatientService Center (PSC) locations.

Such an EHR system may enable access to clinical data for patients inlocations that may comprise a provider's office, a hospital, and aprovider's or patient's home and may provide encryption of data passedover networks comprising, for example, intranets or the Internet.

Embodiments of the invention provide facilities for transferringelectronic messages that have medical data attached. The transfer ofdata is done with no loss of metadata.

For example, a physician using an EHR system may have electronic chartsin the EHR system for one or more patients. Possibly in connection withreferring a patient to another physician, the first physician desires tosend data from the patient's chart to another physician who also usesthe EHR system. Using the EHR system, the first physician creates anelectronic message, selects and attaches the desired data, and thensends the electronic message. On delivery, the recipient can read themessage, view the attached data, and, if desired, save some of all ofthe attached data to the recipient's own copy of the patient's chart.

Depending on the embodiment of the invention, the sender of a messagemay attach any data that a patient's chart contains within the EHRsystem. Such data may comprise, e.g., one or more of the patient'smedical conditions, lab tests ordered for the patient and their results,drug prescriptions, and other data typically found in health or medicalrecords, whether electronic or otherwise.

In an embodiment of the invention, sending data from a patient's chartwith an electronic message involves attaching to the electronic messageunique references to one or more database records that contain the data.In a further embodiment of the invention, when the recipient savesreceived data to the recipient's chart for a patient, the databaserecord or records that contain the data are duplicated, and a referenceor references to the duplicate records are stored in the recipient'scopy of the patient's chart.

In an embodiment of the invention, if the recipient of an electronicmessage containing patient data does not have a chart for that patient,the recipient may create such a chart before adding the received patientdata to it.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated in the figures of the accompanyingdrawings, which are meant to be exemplary and not limiting, and in whichlike references are intended to refer to like or corresponding things.

FIGS. 1 a and 1 b schematically depict networked computer systemssuitable for implementing electronic messaging according to the priorart.

FIG. 1 c schematically depicts networked computer systems suitable forimplementing electronic messaging according to the invention.

FIG. 2 schematically depicts networked computer systems suitable forimplementing the invention.

FIG. 3 depicts a user interface display adapted to navigate anembodiment of the invention.

FIG. 4 depicts a user interface display adapted to search for aparticular patient.

FIG. 5 depicts a user interface display that presents data associatedwith a patient.

FIG. 6 schematically depicts the relationships between payers, insuranceplans, and prescription drug formularies.

FIG. 7 depicts creation of a new prescription according to an embodimentof the invention.

FIG. 8 depicts checking a medication against a particular prescriptiondrug formulary.

FIG. 9 depicts a user interface display adapted to creation of a newprescription according to an embodiment of the invention.

FIG. 10 depicts ordering laboratory services according to an embodimentof the invention.

FIG. 11 depicts a user interface display that presents results oflaboratory tests.

FIG. 12 depicts composing and sending an electronic message according toan embodiment of the invention.

FIG. 13 depicts a user interface display suitable for composing andsending an electronic message according to an embodiment of theinvention.

FIG. 14 is an example of a partial representation of an electronicmessage as XML according to an embodiment of the invention.

FIG. 15 depicts a user interface display suitable for viewing anelectronic message and saving a persistent copy of data attached theretoaccording to an embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Electronic Messaging

FIG. 1 a depicts an example, according to the prior art, of anarchitecture 5 suitable for use in transferring email using the Internet7. A sender (not pictured) interacts with an originating system 10 tocompose an electronic message. Such interaction may take place, forexample, through an email application such as Eudora® or Outlook®, orthrough a web browser, such as Firefox™ or Safari™, that interacts withan email service such as GMail™ or Yahoo!® Mail.

When it is desired to send an electronic message, the message may besent from the originating system 10 to an email server 12. In connectionwith email sent via the Internet 7, the email server 12 locates theemail server 14 associated with each recipient (not pictured) andtransfers the message via the Internet 7. The recipient then interactswith the recipient system 16 to receive electronic messages from theemail server 14. The recipient's interaction with the recipient system16 may take place similarly to the sender's interaction with theoriginating system 10.

FIG. 1 b depicts an alternative architecture 20, according to the priorart, that is also suitable for use in transferring electronic messages.As discussed in connection with FIG. 1 a, above, a sender (not pictured)interacts with an originating system 22 to compose an electronicmessage. When it is desired to send the message, the message may betransferred from the originating system 22 to a mail server 24. Therecipient (not pictured) interacts with the recipient system 26 toreceive the email from the mail server 24.

The architectures depicted in FIGS. 1 a and 1 b may be combined incertain electronic messaging systems. For example, when one user of anInternet service provider (“ISP”) (not pictured) sends a message toanother user of the same ISP, the message may be transferred through anarchitecture 20 such as depicted in FIG. 1 b. When that same user sendsa message to a user of a different ISP, however, the message may betransferred through an architecture 5 such as depicted in FIG. 1 a.

FIG. 1 c depicts one possible architecture 28 (of many) upon whichembodiments of the invention may exist. As in the architecture depictedin FIG. 1 b, a sender (not pictured) interacts with an originatingsystem 22 to compose an electronic message. When it is desired to sendthe message, the message may be transferred from the originating system22 to a mail server 24. The recipient (not pictured) interacts with therecipient system 26 to receive the email from the mail server 24.

The mail server 24 is in communication with a database 30. A databasemay contain one or more records, and one or more identifiers mayuniquely identify a record within a database. For example, relationaldatabase management systems, in which data are represented in tabularform, are well known. A record in such a table may be represented as arow, and a value called a “primary key” may uniquely identify each rowwithin that table.

It is well known that complex data sets and data structures may berepresented by including in a row one or more references to other rowsin the same and/or other tables. Associations between data sets may berepresented in the same way. Such an association may, for example, linkdata with relevant metadata.

The nature of the data store and the reference will depend on theembodiment of the invention. The data store need not be a database 30,as depicted in FIG. 1 c, or a file server, but may be any store ofelectronic data from which a unique reference to data may be used toretrieve that data. For instance, the data store may be part of adistributed object-oriented application, and the reference may be aunique object reference within the system.

The data store need not be in direct communication with the mail server24, as depicted in FIG. 1 c. For example, the originating system 22 mayinsert a unique reference to electronic data into an electronic message.On receipt, the recipient system 26 may then use that reference toretrieve the referred-to data from a data store.

It will be appreciated by those skilled in the art that thearchitectures depicted in FIGS. 1 a-1 c are just a few of many suitablefor the described implementations. More than one component may beinvolved in performing one or more of the functions of the system,depending on the expected load and other factors. Functions depicted asbeing performed by separate components may in some implementations beperformed by a single component, again, depending on the expected loadand other needs of the system. Other configurations of servers andnetwork topologies may work as well as those described here.

EHR Architecture

In the discussion that follows, the invention is discussed in connectionwith EHR systems. Such discussion is meant to illustrate the inventionwith respect to certain preferred embodiments, but it is to beunderstood that the discussion is illustrative and not limiting. It willbe appreciated by one skilled in the art that electronic messagingaccording to the invention may transfer any sort of electronic data byreference, not just medical or health-related data, and not only inconnection with EHR systems.

FIG. 2 depicts an example of an architecture 100 suitable for use withan EHR system.

An EHR system itself may comprise computer software, softwarecomponents, or both, executing on one or more servers 102. One or moreinterconnected local area networks 104 may connect the server 102 to oneor more database servers 106, each of which provides access to one ormore databases 108. The local area network may also contain one or moresystems 110 that provide access to patients' medical histories, whichmay be stored in one or more local databases 112.

In the architecture depicted in FIG. 2, communication with other sourcesand consumers of information is achieved using the Internet 7. Access tothe Internet may optionally be through one or more firewalls, gateways,and/or other security arrangements 117. Other means of communication mayalso be used instead of or in addition to the Internet, such as dial-uplines, dedicated leased lines, and private wide area networks (notpictured).

As depicted in FIG. 2, patient medical data may be stored in one or moredatabases 108, 112 and/or may be obtained from one or more externalsources, such as server 130, which itself has access to a database 132through a database server 134.

Information about health insurance and other forms of payment may bereceived electronically from one or more sources 137. Prescriptioninsurance data, which may comprise formulary data and rules, may also bereceived electronically from one or more sources, such as RxHub® 140.

An EHR system may be connected to one or more medical laboratories 142.Similarly, an EHR system may be connected to one or more pharmacies 144,directly and/or through a prescribing hub such as SureScripts™ 146.

Access to the EHR system is by one or more clients 148.

It will be appreciated by those skilled in the art that the architecturedepicted in FIG. 2 is just one of many suitable for implementation ofthe invention. More than one component may be involved in performing oneor more of the functions of the system, depending on the expected loadand other factors. Functions depicted as being performed by separatecomponents may in some implementations be performed by a singlecomponent, again, depending on the expected load and other needs of thesystem. Other configurations of servers and network topologies may workas well as those described here.

An EHR system may be configured to restrict access to patients' medicalrecords so that only authorized users have access to them. Suchrestrictions may be implemented, for example, to comply with laws and/orregulations concerning the protection of confidential medical data.Access to a particular patient's chart may therefore be restricted,e.g., to a practitioner, or to the practitioner and the practitioner'soffice staff, or those practitioners associated together within aspecific medical practice, among many possibilities.

A user may be a member of one or more health care organizations, and anembodiment of an EHR system may limit users' interaction with the EHRsystem so that a user may be associated with only one such organizationat a time. But such an EHR system may also allow a user to switchbetween those organizations as needed while remaining logged in to theapplication. If a user belongs to more than one organization, that usermay have different permissions under each and may also have access todifferent features of the embodiment. Depending on the EHR system, ifeach organization maintains a separate patient population, a user maynot be able to access patients that exist within one organization whilethat user is logged in under a different organization.

EHR systems typically include means to authenticate the users.Well-known examples of such means include, but are not limited to,requiring a user: to log in with, e.g., a user name and password; toprovide biometric information, e.g., via a fingerprint or retinal scanat the point of use; to provide a physical token or information providedby one, e.g., a temporarily valid access code; or some or all of theseand/or other means. An embodiment may limit access to some or all of thefunctions of the embodiment, including the user interface depicted inFIG. 3 and/or other user interfaces, to successfully authenticated usersor to subsets of them.

FIG. 3 shows an initial (or “Home”) screen 200 of an EHR system that mayserve to allow a user to begin interacting with the system. Thisdepicted screen 200 and those that follow may be used in connection withuse of a thin client, such as a web browser. Other types of clientsand/or other user interfaces (not pictured), with elements thatcorrespond to those described herein as needed by the respectiveembodiments, may also be supported. EHR systems may support interactionwith the user interface by well-known means for interacting withcomputer systems, which may comprise accepting user input via a pointingdevice such as a mouse and a keyboard and displaying output on acomputer monitor.

The Home screen 200 may comprise certain navigation elements and cuescommon to some or all other user interface screens of an EHR system.Such common elements may comprise a function-specific navigation pane202 that contains one or more links for accessing tasks related to thefunctional area currently being used and a function-specific contentpane 204 displays content related to the task currently being performed.

Another such common element may be a navigation bar 210 that providesaccess to a number of general system functions. The navigation bar 210displays the name of the organization or care site 212 currentlyassociated with the user's interaction with the embodiment. If a user isassociated with more than one organization or care site, the user maychoose the one to associate with the interaction by clicking on thisitem.

Selecting the Preferences item 214 allows selection of one of severaluser preference options to see and possibly change. Such options maycomprise, e.g., customizing user preference settings, specifyingfavorite states for pharmacy searches (discussed further below under theheading “ePrescribing”), and changing the user's login password, amongother things.

Selecting the Support item 216 allows selection of one of several usersupport options. Such options may comprise, e.g., sending feedback tosystem administrators, downloading and installing available productupdates, and composing an email to a support team, among other things.

Selecting the What's New? item 218 causes display of informationregarding new features of the system, if any.

Selecting the Help item 220 allows selection of user documentation to bedisplayed. Such documentation may comprise, e.g., online help and/or acomprehensive user manual, among other things. In a particular EHRsystem, the selected documentation may appear in a new window (notpictured) on a computer monitor.

Selecting the Logout item 222 logs the user out of the system. In an EHRsystem that provides user authentication, this may have the effect ofrequiring a user to authenticate anew before using the other features ofthe system.

An EHR system's user interface may comprise functional tabs 240 thatprovide direct access to functional areas of the system. In the systemdepicted, the Home tab 242 causes redisplay of the Home screen 200,which may be updated to display the latest information available.Selecting the Clinical tab 244 provides access to patient-relatedservices, which may comprise, e.g., patient management, lab orders, labresults, and prescription orders. Selecting the Admin tab 246 providesaccess to administrative functions. In typical EHR systems, not allusers have permission to use administrative functions.

Some or all navigation discussed in connection with the navigation bar210, the functional tabs 240, and/or the links displayed in thefunction-specific navigation pane 202 may be provided or duplicated byhyperlinks elsewhere in the screen 200. FIG. 3 shows one example of suchduplication in the form of a cluster 248 of hyperlinks in thefunction-specific content pane 204.

The Home screen 200 may provide access to the most commonly usedfacilities and information provided by the system. The function-specificcontent pane 204 displays a snapshot 250 of many of the activitiesoccurring within the system that relate to the user and associatedpatients. Such a snapshot may comprise a count 252 of the new labresults that have been received, which may be further be broken down bywhether those results are final 254 or partial 256, and may also showwhether any of the results are abnormal. The snapshot may comprise thenumber 260 of new user messages in the user's inbox, the number 264 ofprescriptions that are pending approval, and/or other information.

A user interface to an EHR system may allow direct return from otheruser interface screens to the Home screen 200, displaying snapshot 250,through clicking on the Home tab 242. When the Home screen 200 isalready displayed, clicking on the Home tab 242 may, in some systems,cause the content to be updated to the latest information available.

The Home screen 250 may provide means to navigate the information andfunctions provided by an EHR system. Searching for a patient, forexample, may be done by entering a name in Search field 270. Uponsubmission of the search, the system may cause information to bedisplayed regarding one or more matching patients or notification thatno matches were found. Such information may appear in thefunction-sensitive content pane of Home screen 200, or it may appear inpart of another screen such as patient selection screen 290, which isdiscussed below in connection with FIG. 4.

Other navigational facilities may exist. The function-specificnavigation pane 202 links to other facilities and information providedby an EHR system. Depending on the system and the information currentlyavailable to the user, the links may include, for example, a “NewResults” link 275 that causes the system to display new lab results, ifany, and a “Messages” link 277 that provides access to user messagingfunctionality. Other links may be present for any other informationand/or facility provided by the system.

Navigational facilities may also exist within the function-specificcontent pane 204. For example, in the Action Items area 264, there maybe links to various items that require attention. FIG. 2 depicts such alink to ePrescribing functionality, which is discussed below.

Patient Management

Use of an EHR system may be organized conceptually around one or moreaspects of EHRs or their management. For example, parts of the followingdiscussion and the accompanying figures describe EHR systems thatorganize access to data around individual patients and the respectiverecords that are associated with them. (Following historical practice, acollection of records for a single patient in an EHR system is sometimesreferred to as that patient's “chart.”) It will be obvious to oneskilled in the relevant arts that EHR systems may be organizeddifferently, e.g., around practitioners singly or in groups, payers,hospitals, or pharmacies without affecting the substance of the systemsimplemented or methods performed. It will be equally obvious that EHRsystems may be organized around one or more such aspects and that suchorganization may or may not depend on a particular user's activity atthe time of use.

EHR systems typically maintain EHRs for patients. In that regard, an EHRsystem may provide functionality comprising some or all of adding newpatients, accessing patient charts, viewing patient data, and editingpatient data.

EHR systems may vary in the way they provide for access to patient dataand related functionality. From screen 200 (FIG. 3), a user may selectthe Clinical tab 244 (or the Clinical hyperlink 283), which give accessto functionality associated with clinical practice. Depending on theconfiguration of the system, that selection may lead directly to FIG. 4,which displays a patient selection screen 290.

Some EHR systems may instead be configured to lead to differentfunctionality upon selection of the Clinical tab 244 or hyperlink 283(FIG. 3), and that functionality may then comprise links to screen 290(FIG. 4). For example, a system may cause a link entitled “Find aPatient” 295 to appear in the function-sensitive navigation pane 202when the Clinical tab 244 is selected. Selection of that link 295 thenleads to display of screen 290.

Interfaces to one or more facilities for selecting a patient maycomprise displays that appear in the function-sensitive content pane204. One such display is an area 300 containing a drop-down list 303 ofthe current user's most-recently-viewed patients. (An EHR system may letan administrator set a maximum number of patients that may appear indrop-down list 303.) Once the desired patient is selected, clicking thebutton labeled “Go” 305 then leads to display of records associated withthat patient.

Another such interface is a search area 310 containing one or morecontrols that support searching for one or more patients. Depending onthe system, one or more of the controls may comprise text entry controlsthat let a user specify, e.g., a patient's name 313, Social Securitynumber 315, patient identification number 317, and birth date 319. SomeEHR systems may permit searching based on partial matches, e.g.,returning all records that merely begin with the text entered by theuser or allowing “wildcard” characters in one or more search criteriathat can be matched by any character or string of characters.

The search area 310 may comprise other types of control. For example, adrop-down list 322 may list one or more medical practices or health caresites or facilities with which a user has relationships (collectivelyreferred to as “care sites”). Selecting a care site from the drop-downlist 322 limits the search results to patients affiliated with that caresite.

An EHR system may allow a user to execute a search after entering fewerthan all possible search criteria. For example, an EHR system maysupport searching after the user has entered only the name “Johnson” inthe Name text entry control 313. Other systems may require entry of datainto some or all specific text entry controls before a search can bedone.

After search criteria have been selected, the search may be executed byclicking the button labeled “Search” 325.

The search results area 330 lists patients whose records match thesearch criteria. Hyperlinks 332, 334 lead to display of records relatedto a selected patient. EHR systems may also provide means by which auser may proceed directly from the display of matching patients to oneor more activities involving a selected patient, e.g., writing aprescription, ordering lab tests, or modifying a patient's medicalhistory, among many possible options.

It may be desired to limit the number of matching patients that aredisplayed at once. In that case, a partial list may appear in the searchresults area 330, and a control 340 such as the one displayed may beprovided to support moving backward and forward through the list.

In response to selection of a patient, e.g., via a hyperlink 332, 334,an EHR system may display a summary of data related to that patient,such as the summary screen 360 shown in FIG. 5. In such a system, thesummary screen is a “collapsed” or summarized view of the patient'scomplete chart. The summary screen 360 may initially list only thelatest patient data that is available for quick access and review.Viewing a more detailed history for the patient can be done by clickingindividual items within each section of the summary screen 360.

The summary appears in the function-sensitive content pane 204 of thesummary screen 360. The summary comprises basic information 370 thatidentifies the patient, including, for example, the patient's name 372,DOB (Date of Birth) 374, age 376, gender 378, and PID (Patient ID) 380.

The summary also comprises a display of patient problems and/orconditions, illustrated in FIG. 5 as an editable text area 385 labeled“Patient Problems.” This text area 385 may display any problems or othernotes that have been recorded for the patient. Some EHR systems allowthe user to type notes directly into this control.

An area labeled “Recent Tests” 390 displays one or more lab tests 392that have been ordered for the patient. The details of a result may beviewed by clicking on the name of the test 394.

Some EHR systems may allow viewing of tests by requisition (order). Tosupport this functionality, the user interface screen illustrated inFIG. 5 displays a options (not shown) when the user moves the pointerover the triangle 396 in the title bar 398. For example, in response toa click on the option marked “Requisition” (not shown), tests will bepresented, grouped by requisition. Other systems may support other oradditional options for viewing lab tests, with appropriate userinterface elements to support such options.

Lab tests are discussed in more detail below under the heading “LabOrders and Results”.

An area 400 labeled “Active Medications” displays one or moremedications 402 that have been prescribed for the patient (usingePrescribing, described below under that heading) and are still active.Details may be viewed by clicking the name 404 of a medication 402appearing in this area. The user interface screen illustrated in FIG. 5allows viewing of all medications prescribed for the patient—includingthose that are currently inactive or that have been added from othersources—in response to moving the pointer over the triangle 406 in thetitle bar 408.

An area 410 labeled “Allergies” displays any allergies that have beenrecorded for the patient.

An area 420 labeled “Related Messages” displays user messages 422 thathave been sent that contained a reference to the patient. As displayedin FIG. 5, a user message 422 may contain a hyperlink 424 to moreinformation associated with the message, comprising, for example, thetext of the message and some or all data attached to the message. Usermessages are described in more detail below under the heading“Messaging” below.

Each title bar 430 is a hyperlink or control that gives the user accessto further details about the named area. For example, clicking on the“Related Messages” title bar 432 leads to more information aboutmessages. The new information appears in the function-specific contentpane 204 of user summary screen 360.

An EHR system may support searching for patients from the user summaryscreen 360. For example, the search entry area 435 in thefunction-dependent navigation pane 202 may comprise one or more controls438 for entering partial or complete search criteria. A search may beexecuted by selecting the button 440 labeled “Search”. An EHR system mayprovide a means to reach other searching facilities, such as the searchscreen 290 of FIG. 4, and an example of such means is the hyperlinklabeled “Find a Patient” 442 in the function-specific navigation paneshown in FIG. 5.

EHR systems may also provide user interfaces (not pictured) for addingand/or deleting patients and adding, removing, and/or modifyinginformation associated with patients. Such interfaces may use userinterface components that are well known in the relevant arts.

ePrescribing

EHR systems may comprise an electronic prescribing function, referred toas “ePrescribing.” ePrescribing may automate some or all aspects ofprescription writing and renewal. In preparing a prescription,ePrescribing may retrieve patient benefit information from aninformation source such as RxHub® and its participating Pharmacy BenefitManagers (PBMs), which information may then in some embodiments bedisplayed to the person writing the prescription.

ePrescribing may receive prescription renewals and submit prescriptionselectronically or as faxes through an electronic prescribing networksuch as SureScripts™. Implementations of ePrescribing may supportsubmitting a prescription electronically to the patient's pharmacy ofchoice, and/or printing the prescription for hand delivery to apharmacy. Some or all prescriptions written for a patient usingePrescribing may be stored in the patient's medication history, whichmay be part of the patient's chart maintained by an EHR system. Themedication history can be used to store information about inactivemedications as well as any additional prescription history retrievedfrom PBMs.

An embodiment of ePrescribing may provide various different functionsthat comprise some or all of: displaying information regarding insurancecoverage of medications and, depending on the embodiment, possiblealternatives; checking for drug-to-drug interactions per prescription,and across the patient's medication history; and drug-to-allergyinteractions per prescription. ePrescribing may comprise other functionsrelated to medications, prescriptions, insurance, and/or billing besidesor in addition to those specifically named.

An embodiment of ePrescribing may comprise functions related toprescription drug formularies. A formulary is a list of drugs based on aspecific payer and a specific payment plan. FIG. 6 illustrates therelationship between payers, plans, and formularies. The FIG. 460 showsfour payers 462. Payer 1 (referenced by 464) offers six different plans466. If, for example, Payer 1 is an employer, it may offer its employeessix different plans 466, each offering different benefits and requiringa different contribution from the employee. Each of these plans 466 isassociated with its own distinct formulary.

Similarly, Payer 2 (referenced by 470) offers six different plans 472,and each plan is associated with its own distinct formulary.

Embodiments of ePrescribing may maintain an Active Medications list forpatients. When used to create a prescription for a patient, ePrescribingmay automatically save a record of each prescribed medication to thepatient's Active Medications list, which may be accessible from thepatient's summary, displayed in the patient summary screen 360 (FIG. 5).Medications can also be added manually to a patient's Active Medicationslist by activating previously inactive medications for whichePrescribing has a record and/or by adding them from a list ofprescriptions maintained by one or more PBMs.

Embodiments of ePrescribing may support user-specified rules that governthe contents of an Active Medications list. For example, a rule may setthe maximum time that a prescription may be considered “active.” Afterthat time, a prescription may be removed from the patient's ActiveMedications list, but may or may not be retained in other records.ePrescribing may also support manual addition to and/or removal from theActive Medications list.

An embodiment of ePrescribing may provide several different ways todisplay information about a patient's medication history or subsets ofit. For example, the Active Medications list and/or the list of allmedications on the patient's chart may be displayed and may be sortedaccording to one or more criteria.

When displaying details of a particular medication, an embodiment ofePrescribing may permit the user to view and/or print a copy of theprescription.

FIG. 7 illustrates how a new prescription may be written 500 inassociation with an ePrescribing. At block 505, a patient's chart isaccessed, possibly as described in connection with FIG. 4, above. Oncethe patient has been selected, the user may begin 507 creating theprescription.

At block 509, the identity of the health care provider who is writingthe prescription is selected or confirmed. In some EHR systems, theuser's login information may serve to identify a default provider, whomay be the user. Some systems may permit overriding the default choice.Some may limit the choice of provider to one or more providers who havepreviously been associated with the user.

A destination may be assigned 511 to a prescription. Depending on theembodiment of ePrescribing, possibilities may comprise one or more of,e.g., sample or handwritten prescriptions, prescriptions sent topharmacies electronically or by fax, and prescriptions sentelectronically to mail-order prescription sellers.

Sample prescriptions may represent drugs dispensed directly by theprovider, which may be samples provided to the provider by drug makersor distributors. Handwritten prescriptions may, for example, be printedby an embodiment of this application and then manually signed by theprovider or manually written in their entirety by the provider.Handwritten prescriptions may be used, for example, where a pharmacy isnot equipped to receive prescriptions electronically or by fax, or whereapplicable law or regulation requires a paper prescription bearing anauthorized provider's original signature.

If the prescription is to be sent directly to a pharmacy, block 511 maycomprise selection of the recipient pharmacy.

In block 513, a medication is selected for prescribing. Once themedication and the patient are selected, one or more checks may beperformed against one or more databases. Depending on the embodiment ofePrescribing, such checks may comprise, for example, one or more ofchecking the formulary 515 applicable to the patient; checking the drugagainst the patient's known allergies 517; and checking for interactions519 between drugs that the patient is known to be taking. Block 521represents presentation to the user of the results of some or all ofthese checks.

After reviewing any results of any checks, the provider may confirm 523the selected drug or to go back choose another medication 513. Once theprovider confirms a selected medication, other details of theprescription may be provided 527. Depending on the embodiment ofePrescribing, such details may comprise one or more of, for example, thedosing frequency, the amount of the medication to be dispensed, thelength of time that the patient ought to take the drug, the number ofrefills allowed, and whether a brand-name drug, if prescribed, may bereplaced by its generic equivalent, if any.

An embodiment of ePrescribing may support prescriptions that compriseone or more medications. In such embodiments, block 529 represents thechoice to add a medication to the prescription that is in progress.

Following selection of desired medications, block 531 representsdisposition of the prescription. Depending on the embodiment ofePrescribing and/or the options associated with the prescription,possible dispositions may comprise, for example, printing a prescriptionfor manual signature, transmitting the prescription to a pharmacyelectronically or by fax, and/or storing the prescription for possiblefuture action, possibly comprising, among other things, electronicreview by a payer. Block 533 represents addition of a prescription to apatient's chart.

Embodiments of ePrescribing may support the association (not pictured)of notes with a prescription and/or some or all of the medicationscontained in it.

FIG. 8 elaborates a possible implementation 550 of checking a formulary.Formularies exist because formulary management may benefit payerorganizations. The payers make available the different formulary optionsto meet both the financial needs of an employer and the benefit needs ofemployees. But since there are thousands of payers and each payer canhave several plans, there are thousands of plans and formularies, all ofwhich may need to be managed.

In block 552, the patient's eligibility for a particular plan is checkedagainst one or more databases. If the patient is eligible, then theappropriate formulary for that plan is retrieved in block 554.

From one or more databases, from the formulary, or both, a list of drugssimilar to the prescribed drug is retrieved in block 556. A “similar”drug here is a drug with some or all of the same indications as theprescribed drug, or a drug that is prescribed in similar circumstances.

In block 558, the validity of the prescription is checked against theformulary. Finally, in block 560, the results of the other blocks arereturned. In some implementations of ePrescribing, the provider will betold that the prescribed drug is or is not on the formulary and willalso be shown the list of the similar drugs that were identified inblock 556. If the information is available to the electronic prescribingsystem, the provider may also be told what co-payment will be requiredfor the drug.

Other ways (not pictured) exist to check formularies. For example, allrelevant formulary data may be obtained at the commencement of anePrescribing operation. Then, before any information regarding a drug ispresented, that drug is checked against the applicable formulary, andthe displayed information reflects he formulary status of the drug.

FIG. 9 depicts an example of prescription writing screen 580 that may beused in association with embodiments of ePrescribing.

As in other example screens, the prescription-writing screen 580displays basic information 370 that identifies the selected patient. Anarea 585 holds information about the patient's pharmacy benefits, ifknown. The information comprises the name of the PBM 587 from whichformulary information will be retrieved, if available.

A pharmacy display area 590 holds information about the currentlyselected pharmacy, which may comprise, for example, the name 592,location 594, and telephone number 596. An embodiment of ePrescribingmay set a default pharmacy that may be accepted or modified. A user mayselect a new pharmacy by following a hyperlink 598, to a screen (notpictured) from which the user may search for a pharmacy, or by followinga hyperlink 600 to a display (not pictured) of one or more “favorite”pharmacies, the contents of which depend on the embodiment.

An embodiment of ePrescribing may allow the user to add pharmaciesmanually (not pictured). Depending on the embodiment, an administratormay allow only a subset of users to add pharmacies manually. Someembodiments may support limiting use of such manually-added pharmaciesto one or more subsets of users, and such individual limitations may ormay not apply to individual pharmacies and/or one or more classes ofpharmacies.

A medication selection area 605 supports searching for a medication toadd to the prescription. After a partial or full name of a medication isentered into the text entry control 607, clicking the button labeled“Search” 609 executes a search. From the results of such a search (notpictured), the user may select a medication to prescribe. Embodiments ofePrescribing may also support conducting further searches or other meansof selecting a medication once a search has been performed. Also in themedication selection area 605 is a hyperlink 611 that leads to a display(not pictured) of one or more “favorite” medications, the contents ofwhich depend on the embodiment. Selection of a medication may causedisplay (not pictured) of one or more forms and/or dosages in which thatmedication may be dispensed.

Any display of information related to a medication may compriseinformation regarding the formulary status of that medication. Many waysof conveying such information are well-known, and may comprise, e.g.,arranging names of medications in a display; providing textual labels;visually associating one or more icons with the displayed medication;and/ or varying the typeface, size, style, color and/or other attributesof the text used; among other indications.

In addition to or instead of the preceding, any display of informationrelated to a medication may comprise information regarding interactionsbetween that medication and a patient's allergies and/or othermedications that a patient is known to be taking. Display of suchinformation may take varying forms as above.

Display of information related to a medication may comprise display ofinformation regarding other medications, comprising, for example,generic equivalents to a medication and/or possible alternatives to amedication.

The Rx Box 615 displays a selected medication 617 and its dosage andform 619. It contains controls that support entry or modification ofinformation associated with a prescription, such as the dose 621,frequency 623, amount to be dispensed 625, duration of the prescription627, number of refills permitted 629, authorization to dispense ageneric equivalent instead of a brand-name drug 631, and notes 633, ifany, for the pharmacy. A code 635 indicates the preferred route foradministration of the medication. Some embodiments of ePrescribing maycause additional and/or different controls to be displayed.

As illustrated, the dose 619 is a hyperlink to a screen (not pictured)allowing selection of a different dose, if available.

A destination area indicates where a complete prescription is to besent. As depicted, the options presented comprise “Send to Pharmacy”642, “Sample/Handwritten” 644, and “Mail Order” 646. Options may bedisabled depending on circumstances. For example, when used to create aprescription for a controlled substance that may be dispensed only upona manually signed prescription, an embodiment of ePrescribing maydisable the “Send to Pharmacy” 642, and “Mail Order” 646 options.

Once a medication has been selected and appropriate parameters set, abutton 650 allows addition of the medication to the currentprescription. Another button 652 causes removal of the medication fromthe current prescription. A button 654 is provided to clear thecurrently-entered values.

Embodiments of ePrescribing may provide functionality and interfaces(not pictured) supporting renewal of previous prescriptions and/or forusing previous prescriptions as models or templates for new ones.

Screen 580 also displays a control 657 that supports entry of officenotes that are associated with the prescription as a whole, but may ormay not be associated with any individual medication contained in theprescription. Depending on the embodiment of ePrescribing, such officenotes may or may not appear on a prescription itself.

Screen 580 displays controls 660, 662, 664, 666 associated with thedisposition of prescriptions. Depending on the embodiment ofePrescribing, a button 660 causes a prescription to be printed, an imageof a prescription to be displayed that may itself be printed, or both. Abutton 662 indicates approval of the prescription as currentlydisplayed. Selecting this button 662 may cause the prescription to besent to the selected pharmacy, to be held pending approval by a PBM,and/or other possible dispositions. A button 664 causes the prescriptionto be saved as a pending prescription, and, in some embodiments, theprescription may be held pending approval by a PBM. Finally, a button666 may cancel a prescription.

Information about pending and sent prescriptions may appear on screen200 (FIG. 3) in the Action Items area 264 (FIG. 3). Such information maycomprise, for example, the number of pending prescriptions and/or thenumber of electronic or faxed prescriptions that failed to reach theirdestinations. In some embodiments of ePrescribing, a hyperlink such asthe hyperlink 280 (FIG. 3) illustrated may lead to a display (notpictured) adapted to resolution of one or more such action items.

The preceding description of ePrescribing is meant to be illustrative,not limiting. Embodiments of ePrescribing may provide functionality anduser interfaces different from and/or in addition to those described.Tools may be provided to search, retrieve, display, modify, and/orotherwise manipulate data associated with prescriptions and/orassociated medications, whether singly, in groups, or both.

Lab Orders and Results

EHR systems may support entry of orders for lab services and/or displayof results of lab tests. More particularly, a user interface may supportspecification of one or more lab tests to be performed and, depending onthe system, may automatically submit a request for such tests to aprovider of lab services (a “lab”). Automatic submission of a requestmay take place electronically, by fax, and/or by other means. Labs mayprovide test results for storage, processing, and/or display. An EHRsystem may insert some or all lab orders and/or results into theinvolved patient's chart.

EHR systems may support entry of orders for lab services and/or displayof results of lab tests.

FIG. 10 depicts how a new order (also called a “requisition”) may becreated 680. In block 682, a user interface adapted to creation of anorder is displayed. In block 684, a patient is associated with thisorder. If order creation 680 has been initiated from a screen such aspatient summary screen 200 (FIG. 3), a patient may already be associatedwith this order. An EHR system may provide functionality as alreadydescribed herein to select a patient to associate with this order.

Block 686 represents selection of the health care provider who isordering the test. EHR systems may support use of one or more uniquecodes and/or identifiers in connection with selection of a provider. Forexample, an EHR system may restrict the ability to order lab tests tophysicians, and such a system may support use of the orderingphysician's Medicare Unique Physician Identification Number (“UPIN”) touniquely identify that physician.

An EHR system may support entry 688 of billing information for theassociated patient and/or verification of such information alreadyprovided. Such information may comprise, for example, the name of theperson who bears financial responsibility for the patient and/orinformation regarding the patient's insurance or other paymentarrangements. An EHR system may use this information in conjunction withone or more facilities for automating payment, billing, and/orcollection.

In block 690, one or more diagnoses associated with the patient may beentered. Diagnoses may be represented by one or more codes, e.g., codesfrom the standard International Classification of Disease (ICD). An EHRsystem may accept locally-defined codes in addition to or instead ofstandard codes. Similarly, an EHR system may accept textualspecifications of diagnoses in addition to or instead of codes of anysort.

One or more specimens may be subjects of lab tests. Block 692 representsentry of information regarding a specimen associated with a test order.Such information may comprise, for example, the date and time thespecimen was collected, the volume of the specimen, and/or whether thepatient fasted. An EHR system may vary the information collecteddepending on which test is selected and/or may refuse to accept an orderthat omits some or all information.

In block 694, depending on the system, one or more lab tests may beselected. Also depending on the system, a user may select from testsoffered by one lab or from a plurality of labs.

An EHR system may provide access to one or more tests that requireadditional information before a lab can perform the tests. In block 696,such Ask at Order Entry (“AOE”) information can be obtained and added tothe order information.

An EHR system may use entered patient, payment, diagnosis, order, and/orAOE information to verify (not pictured) that a test order will becovered by the patient's payment plan. Such a system may indicatecoverage status visually.

Block 698 depicts review of entered order information. In some EHRsystems, creation 680 of a lab order may be interrupted (not pictured)at this point, with the order information stored for future use. In sucha system, such stored information may be retrieved and the ordercompleted. Once the information is believed correct, the order may besent in block 700 to, depending on the embodiment, one or more labs forprocessing. In block 702, a sent order may be stored, possibly inassociation with the patient's chart.

Sending an order as depicted in block 700 may comprise sending the orderto a lab electronically, by fax, and/or other means, depending on theEHR system and/or its configuration.

Following creation 680 of a lab order as depicted in FIG. 10, an EHRsystem may arrange automatically for retrieval (not pictured) of thephysical specimen or specimens associated with one or more orderedtests. Such arrangements may comprise, for example, adding the locationof the health care provider's office to the route of a courier who picksup such specimens. In some EHR systems, an order may request that atechnician be dispatched to the patient's location (e.g., home oroffice) to obtain a sample. Another possible arrangement may involveautomatic generation of shipping orders and documents for a commoncarrier such as UPS® or FedEx®. It will be appreciated that many othersuch arrangements are possible.

An EHR system may support variations of lab order creation 680 inaddition to or instead of creation 680 as depicted. For example,information entered as described may serve to create a standing laborder, which may be repeated as specified by the user. Apreviously-entered order may serve as a template for creation of a neworder. Many other variations are possible and may be supported by an EHRsystem.

Test results may be provided electronically to an EHR system. An EHRsystem may accept result in other forms, e.g., results printed on papermay be accepted via optical scanning or manual data entry. Other ways toprovide and accept test results are apparent. An EHR system may accepttest results regardless of whether a test was electronically ordered.

An EHR system may receive one or more test results that lack informationsufficient to match the results with a requisition or a patient. Asystem may thus provide one or more facilities for matching such orderswith the corresponding records.

FIG. 11 depicts the test result screen 730 that may appear in an EHRsystem. An EHR system may provide one or more ways to reach testresults, and one way that the depicted screen 730 may be reached is fromthe patient summary screen 360 (FIG. 5). The test result screen 730comprises basic information 370 that may identify the patient associatedwith a test. The test result screen 730 may comprise other informationabout the test results and the associated requisition, e.g., arequisition number 740, the prescriber's name 742, the patient's name744, the date and/or time when the tested sample was obtained 746,and/or a summary 748 of the test results, among other things.

Test details 756 may be presented. A title bar 758 indicates the name759 of the test and/or panel of tests. Below the title are the results760 of one or more tests.

As illustrated in the test result screen 730, a test result 760comprises the name 762 of a substance or property (either may be calledan “analyte”) for which a test was performed. The result 760 may alsocomprise a short description 764 of the test or analyte; a numberrepresenting the value 766 of the analyte; and/or the units 768 of themeasurement. For reference, a range 770 of typical values for theanalyte may be provided, as well as one or more visual indications 772that a measured value is abnormal.

For example, the test result screen 730 illustrates the results of apanel of tests called a “Basic Metabolic Panel.” One test in the panelis a test for potassium 774. The reference range 770 for potassium isbetween 3.5-5.3 millimoles per liter, but the test measured only 1.0millimoles per liter 766. A “<” character 772 thus appears to the rightof this abnormal result, indicating that measurement was below a rangethat may be considered normal. A user interface screen may compriseother indicia of abnormal test results, e.g., symbolic icons and/or textcoloring.

Test results over time may be presented. For example, graphs and/orcharts (not pictured) may depict the values of one or more tests overtime. A report may present the same information textually. Other ways ofpresenting test results will be apparent, and an EHR system may compriseany or all such presentations.

An EHR system may comprise search, retrieval, and/or report generationfacilities (not pictured). Such facilities may, depending on the system,comprise manipulation of one or more test results for one or morepatients, individually or collectively. For example, an EHR system mayallow a user to search for results of all glucose tests given in thepast month to male patients between the ages of 45 and 59, in which thetest detected an abnormal level of glucose. Such facilities may serve,for example, to identify clusters of abnormal test results, which may insome circumstances signal a spreading health problem. An EHR system maycomprise tools for creating graphical and/or textual reports of suchsearches.

User Messaging

An EHR system may comprise an electronic messaging facility thatembodies this invention. According to such an embodiment of theinvention, users can communicate with other users whether they reside inthe same organization or care site, reside in a separate physical officelocation, or are members of a separate organization. An embodiment ofthe invention may make it possible to refer, within the user message, tospecific clinical acts for a patient, including, for example, labreports, medications, and/or allergies. This function may be desirablefor purposes related to patient care, including, for example: patientreferrals; answering of patient questions; and providing careinstructions to other clinicians.

FIG. 12 depicts composing and sending 800 a message in accordance withan embodiment of the invention. An EHR system may support one or moremeans to begin 802 composing a message. For example, in the patientsummary screen 360 (FIG. 5), the function-dependent navigation pane 202(FIG. 5) may contain a hyperlink 446 (FIG. 5) to a user interface thatsupports composing a message.

In block 804, the user may specify one or more message recipient(s). EHRsystems may differ on how recipients are specified. For example, anembodiment provide a control (not pictured) in which a name or addressof a recipient may be entered. An EHR system may provide the names ofone or more known users, from whom one or more recipients may beselected. These and other ways of selecting recipients are well known inconnection with electronic messaging, and EHR systems may support one ormore such ways.

Other information may be entered; for example, an embodiment of theinvention may support entry of a message subject 806, a reason fordisclosure of patient information 808, and/or the content of the message810. An embodiment may, for example, support entry of a reason fordisclosure of information to track the distribution of healthinformation that is required by law to be kept confidential.

If desired, clinical information from a client's chart may be attached812 to the user message. The user message may then be sent 814.

The message composition screen 830 of FIG. 13 depicts a user interfacedisplay adapted to composing and sending a user message. A text box 832contains the names of one or more recipients. Depending on theembodiment of the invention, recipients' names may or may not bedirectly entered in text box 832.

Recipients may also be entered by following the hyperlink 834 labeled“Search Recipients.” The hyperlink 834 may lead to a display (notpictured) allowing entry of one or more criteria to be used to searchfor potential recipients of the message. The hyperlink 834 may leadalso, depending on the embodiment, to a display (not pictured) of thenames of one or more recent recipients of user messages. Depending onthe embodiment of the invention, one or more recipients may be addedthough either means or both. Embodiments of the invention may provideother ways to add recipients in addition to or instead of the onesdescribed here.

Text areas support entry of a subject 836 for the message and themessage body 838.

The hyperlink 840 labeled “Search and attach a patient chart” may serveto attach chart data to a message. When followed, the hyperlink 840 maylead to a user interface that supports selecting a patient, such as, forexample, the patient selection screen 290 depicted in FIG. 4. In someembodiments, if message composition was initiated from a screenassociated with a patient, such as, e.g., the patient summary screen 360depicted in FIG. 5, searching for and/or selecting a user may beskipped.

Depending on the embodiment of the invention, once a patient has beenselected, a screen such as the patient summary screen 360 (FIG. 5) maybe displayed. That screen, in turn, may be used to access that patient'schart data. Individual items of data may be selected. Once desired itemshave been selected, a hyperlink (not pictured) or other means may enablereturn to the message composition screen 830. Upon return to the messagecomposition screen 830, the selected data items will have been attachedto the message. Embodiments of the invention may support removal ofattached data from a draft message and/or attachment of further data.

The button 842 labeled “Send” allows sending the message, including anyattachments. The button 844 labeled “Cancel” allows cancellation of apending message. An embodiment of the invention may also provide means(not pictured) by which a draft of a message may be saved and then sentlater, possibly after further revision.

In an embodiment of the invention, the message composition screen 830may comprise a control 846 for entry of one or more reasons fordisclosure of patient information. Such reasons may be legally requiredor otherwise desirable.

FIG. 14 is a partial representation of an electronic message 862 withattached chart data according to an embodiment of the invention. Therepresentation uses the eXtensible Markup Language (XML), which is awell-known tool for representing structured data for storage,processing, and/or transfer.

The representation of the message 862 comprises three top-levelcomponents. The first top-level component is the header 864, which,depending on the embodiment of the invention, may comprise informationrelevant to handling the message, e.g. , the sender 866, the recipient868, and/or the subject 870 of the message, among other things.

The second top-level component is the body 874, which in thisillustration contains only the text of the message.

The third top-level component is the attachment element 880, which maycomprise zero or more attachments 882. The illustrated representationdoes not directly represent attached chart data, but instead contains areference 884 (often called a “pointer”) that uniquely refers to aspecific entry on a specific patient's chart. The meaning and resolutionof references depends on the embodiment. One possible meaning (of many)is that the reference 884 is a unique identifier that is part of therecord of the chart item that appears in one or more tables in arelational database management system. The existence of a uniqueidentifier called a “primary key” is well known in the relevant arts,and some embodiments may use a representation of a primary key as areference 884 to chart data.

The XML fragment of FIG. 14 serves primarily to illustrate the data thata message may in some embodiments comprise, by depicting certain aspectsof data associated with a message and one possible representation ofthose aspects. It will be appreciated that different and/or additionaldata may be associated with a message and that many otherrepresentations are possible, including, for example,differently-structured XML documents and/or representations other thanthose using a markup language such as XML. For example, an embodiment ofthe invention may store data associated with a message in one or morefields of one or more tables in a relational database management system.

An embodiment of the invention may use the reference 884 to identify theitem of chart data referred to. This process may be called“dereferencing.” Dereferencing a pointer reveals an item of chart data,which the recipient may view. If the item is saved to a patient's chart,an embodiment of the invention may duplicate the item and then save thenew copy in association with the recipient's version of that patient'schart. Instead of duplicating an item of chart data, an embodiment ofthe invention may give the recipient direct access to the item on thesender's chart.

Some embodiments of the invention may support both options, choosing oneor the other based on circumstances. For example, if the sender andrecipient are in practice together, they may have access to the samecharts. In that case, viewing an attached item of chart data maycomprise accessing the shared chart. If the sender and receiver are notin practice together, the recipient may lack privileges to access thesender's chart directly, and the attached chart item may then beduplicated, and the copy saved, as already described.

After an electronic message has been delivered, it may be viewed, and,in some embodiments of the invention, some or all attached data may beviewed and/or saved to a patient's chart. FIG. 15 depicts a userinterface display 890 that an embodiment of the invention may use topresent a message and attached data and to allow the recipient to viewattached chart data and possibly to save it.

The message display may be divided into three areas. A header area 895may display information about the message itself. In an embodiment ofthis invention, this information may comprise, e.g., the recipient 897and sender 898; a subject, title, or summary of the message 899; thereason 900 for disclosing the attached patient records (if any) to therecipient; and the time 901 when the message was sent. The header area895 may display other information in addition or instead of the depictedinformation.

A body area 905 displays the body 907 of the electronic message. In anembodiment of the invention, the body 907 comprises text. In otherembodiments of the invention, the body 907 may comprise images and/orother multimedia content (not pictured) and/or hyperlinks to other data(not pictured).

An attachments area 910 displays information associated with attachments912, if any, to the electronic message. In the depicted embodiment ofthe invention, each line comprises a summary of information about asingle attached chart item. For example, the first displayed chart itemis a prescription 913. The display is a summary that comprises an itemnumber 914 that uniquely identifies the chart item within the EHRsystem, the name 915 of the prescribed drug, the form 916 of the drug,and the date of the prescription 917. One or more of the components ofthe summary of the prescription 913 may act as hyperlinks to furtherdata (not pictured) related to the chart item.

The next displayed chart item is a panel 920 of laboratory tests. Thedisplay is a summary that in the depicted embodiment of the inventioncomprises an item number 906, the name and date 922 of the test panel,and a code 924 indicating the status of the panel 920. The codes andtheir meanings depend on the embodiment of the invention, but in thedepicted embodiment, the code “F” indicates that the status of the testpanel 920 is “final,” which means that results are available for alltests 928 comprised by the panel 920.

A panel comprises one or more laboratory tests. The panel 920 depictedin FIG. 15 comprises blood tests for glucose 930 and urea nitrogen 932,among others. In the depicted embodiment of the invention, theinformation for each test comprises the name 936 of the analyte, thevalue 938 detected by the laboratory, a “reference range” 940, which mayrepresent a range of typical values for the analyte, and the units 942of measurement in which the data are presented.

The panel 920 may be regarded as a single data item, as may be theprescription 913. But it comprises several tests 928, each of which mayitself be regarded as a data item. The panel 920 may therefore bedescribed as a hierarchical data item, and may be viewed either on asingle line as a single data item or on multiple lines as an objectcomprising multiple data items. The triangle 936 is a control thattoggles between the two views of the panel 920.

If, as in the depicted user interface display 890, full display ofinformation about the attachments would exceed the available space inthe attachments area 910, the attachments area 910 may contain a control946 supporting scrolling through the displayed list of attachments.

Each data item in the attachments area 910 is associated with a checkboxcontrol 938, by which a user may choose to save that chart item to achart managed by that user. In an embodiment of the invention, selectinga checkbox control 938 next to a hierarchical data item may causeselection of each data item that it comprises. In such an embodiment,the user may then deselect individual data items to exclude them fromthe chart.

Once the user has selected one or more attached data items, the user maythen select the save button 940, causing the system to save a persistentcopy of each selected data item to a chart managed by the user. In sucha case, an embodiment of the invention may first check that therecipient has a chart for the associated patient, and, if not, permitthe recipient to create one. Creation of a patient chart by therecipient may in an embodiment rely on some or all demographicinformation present in the sender's version of the patient chart.

The copy is considered a persistent copy because it resides innonvolatile storage and is not regarded by the system as a temporaryfile that may be subject to routine deletion.

In creating copies of attached data, an embodiment of the invention maynot be limited to the one or more data sets that the reference directlyspecifies. An embodiment may follow references to associated data tocreate a copy or copies of related data, including data providingsemantic data, and to associate these copies with the copy of thedirectly-referenced data. The embodiment may follow such links to copyassociated records to any desired level of indirection. For someassociated data, copying the reference to the associated data maysuffice.

For example, data for a single test result may be associated with a setof data describing the data sample, a set of data describing the testpanel, and/or a set of data related to payment for the test, among manyother things. The result data may also be associated with informationdescribing the vendor of laboratory services and/or the specificationsfor the particular test, again, among many other things. In anembodiment of the invention, copying the chart item containing such atest result may therefore comprise, e.g., copying all records specificto the test and/or patient, but copying only references to data thatdoes not vary from test to test and/or is not specific to the particulartest, panel, and patient.

In making such a copy, an embodiment of the invention has access to alldata and metadata, including semantic data, that the sender has accessto. Such an embodiment may thus preserve any or all such data whencopying the data for the recipient.

Embodiments of the invention may comprise facilities for managing usermessages. Such facilities are well known and may comprise, for example,one or more of: viewing sent or received messages; filtering messagesaccording to one or more criteria; deleting messages, replying tomessages, forwarding messages to other users; sending messages via fax;searching and/or retrieving stored messages; and/or other facilities.

1. A method for duplicating data associated with semantic data,comprising: receiving an electronic message that comprises at least onereference that uniquely specifies a set of data, wherein the set of datacomprises one or more original data items that are associated withsemantic data; presenting the electronic message to a recipient at afirst computer system; in response to input to the first computersystem, presenting at the first computer system some or all of the datacomprised by the set of data; and in response to further input to thefirst computer system, creating a persistent copy of some or all of thedata comprised by the set of data; wherein creating a persistent copycomprises creating a persistent copy of at least one of the one or moreoriginal data items that are associated with semantic data, such thateach copy of a data item is associated with the same semantic data thatthe corresponding original data item is associated with.